1. Field of the Invention
The present invention is in the field of resource management for resources within a computer system. In particular, the present invention provides a method of generating an object-oriented resource wrapper for use in managing a resource.
2. Description of the Related Art
To complete a given task on a modern computer system, the computer system will typically employ a myriad of hardware and software resources. These resources may comprise local software applications, hardware devices, data, or implementations of a remote software service. As the complexity of these systems has grown, so has the need to efficiently manage and configure the resources available.
Many resources within modern computer systems can be configured using so-called configuration files. FIG. 1A illustrates the management of a resource according to these prior art methods. Resource 120 is typically associated with computer system 130 and an accompanying configuration file 110. Configuration file 110 comprises one or more configurable parameters relating to resource 120. When the computer system interacts with or runs resource 120, it makes use of configuration file 110 to appropriately set the configurable aspects of the resource 120. For example, if resource 120 comprises a software application, then configuration file 110 may comprise a parameter setting the default path for file access. In real-world implementations, a modern software application may have over ten different configuration files that expose over five hundred different attributes. Each of these attributes may be modified by a user to affect the behaviour of the software application. Using configuration files to manage the resources of a computer system provides a workable solution to the problem of resource complexity. However, in itself, this solution also introduces a number of further problems of its own.
A first problem is that often the configuration file 110 contains attribute fields that can only be understood by the developer of the resource. For example, a configuration file for a peripheral hardware device will be typically produced, and only understood, by the engineer, or team of engineers, responsible for the creation of the device and a configuration file for a software application will be typically produced, and only understood, by the programmer, or team of programmers, responsible for coding the application. In the latter case, the form and syntax of the configuration file may be intricately linked with the form and syntax of the software application. A user unfamiliar with the form and syntax of the software application will thus not be able to alter the configuration of the resource 120 by directly altering the configuration file 110, even if they are familiar with the language in which the configuration file is written. If a user unfamiliar with the intricate workings of the resource attempts to set configuration parameters and incorrectly edits the configuration file 110, then the accompanying resource 120 will not be configured correctly, increasing the likelihood of errors. Incorrect parameters set for a hardware device may cause the device to fail and incorrect parameters for a software application may cause the application to crash.
To increase the usability of configuration files, and to overcome the problem above, some technical developers began to provide user-friendly applications for configuring the parameters of the resource 120 in the configuration file 110. For example, a software application may provide a specially designed graphical interface for viewing and setting resource parameters. Such interfaces could also be adapted to provide advance features such as error checking and automatic updates; typically the user would alter the parameters in a graphical user interface and the configuration file would be updated behind the scenes when the user pressed a “SAVE” button.
While the provision of configuration applications facilitated the updating of configuration files, it also generated another problem in that the user now had to be familiar with the specific configuration applications for a particular resource. Moreover, each configuration application typically provided a different user interface and a different method of updating configuration files. Therefore, to further facilitate the process of updating configuration files, a number of resource management standards were agreed upon. These standards were typically accompanied by a standard set of application programming interfaces (APIs) that enabled a number of heterogeneous resources to be managed in a common manner. Different standards were typically developed for different programming languages and the Java standard is referred to as Java Management eXtensions (JMX). FIGS. 1B and 1C show prior art methods of resource management using standardised interfaces.
FIG. 1B shows a computer system 130 with an associated resource 120 and a configuration file 110 as found in FIG. 1A. However, in FIG. 1B, a management application 140 is used to configure the resource 120. The management application 140 is typically built upon a set of standards such as the JMX standard for the Java language which provides a number of APIs designed specifically for resource management. All of today's large application vendors provide built-in JMX management applications inside their application servers. For example Oracle, JBoss, Sun and other companies provide stand-alone applications that are specifically designed to manage configuration files using JMX technology.
In order to allow the management application 140 to interact with a number of configuration files 110 of different types and form, a configuration wrapper 150 is provided. For example, in an object-oriented programming environment, the configuration wrapper 150 may comprise a software object that models the resource 120. The JMX standard requires that developers “wrap” their configuration files in Java software objects called MBeans (Management Beans). The process of “wrapping” a resource typically comprises modelling the resource using one or more software objects. This MBean may encapsulate other lower level software objects and provides standardised methods for accessing and writing configuration information to a configuration file 110. For example, the software objects may provide “GET” methods to retrieve configuration parameter values associated with the resource 120 and “SET” methods to save configuration parameter values associated with the resource 120. The configuration wrapper 150 thus provides an interface between the management application 140 and the actual configuration file 110. The JMX standard then allows developers to use management applications that can read data associated with MBeans and provide a management user interface to edit values associated with the resource 120.
FIG. 1C shows an extended schematic diagram of the use of configuration wrappers to manage several different resources. FIG. 1C shows a computer system 130A, a resource 120 and a first configuration file 110A as shown in FIGS. 1A and 1B. The first configuration file 110A has an associated configuration wrapper 150A. The system 130A is connected to a network 170. In this example, computer system 130A is connected to computer system 130B and hardware device 160 through the Internet 180. Computer system 130B runs management application 140 which is configured to manage resource 120 and hardware device 160. Management application 140 thus accesses and modifies configuration information for resource 120 via configuration wrapper 150A associated with configuration file 110A. In FIG. 1C, hardware device 160 also has an associated configuration file 110B. This configuration file may contain settings such as memory and cache settings, memory or IP addresses for the device, interrupt request (IRQ) priority and/or any other operating parameters of the hardware device 160. In the example shown in FIG. 1C, configuration file 110B has two associated software objects for reviewing and setting configuration data contained in the configuration file 110B. For example, the first configuration wrapper 150B may comprise a software object such as an MBean that is configured to access and modify the network properties of the hardware device 160. The second configuration wrapper 150C may then comprise another MBean software object that is alternatively configured to access and modify configuration data relating to memory use and access. Using configuration wrappers 150A, 150B and 150C, a user of computer system 130B can manage a plurality of resources using management application 140 and can manage resources that are located either remotely or locally.
However, the use of standards such as JMX comes at a price to developers. In order to “wrap” a resource using a software object, the variables and methods of the software object must be defined by the developer based on the properties of the resource and the resource's configuration file, i.e. an MBean must be manually generated by the developer of the resource 120 based on the form and syntax of the configuration file 110. For example, if configuration file 110 comprises a parameter such as “file path”, then the configuration wrapper 150 would need to contain an internal property such as “file_path” and a method for accessing and setting this property, for example a “GET.file_path” method. The methods of the MBean are set out in program code within the class definitions for the MBean and are written by the developer of the resource 120 using their knowledge of the resource 120 and configuration file 110. While the development of software objects many be tractable when dealing with a small number of resources, generating software objects to manage a large number of resources and configuration files can take an exceedingly long amount of time, especially if each file has a large number of configuration attributes and there are a large number of resources or configuration files. For example, when using the JMX standard, a developer will need to generate the class files to implement the MBean and will need to set the attributes and methods of the MBean within these class files based on the format of the configuration file.
A further problem also arises when attempting to maintain software objects relating to the resource and the resource's configuration files. When a resource is altered or updated, for example patching a software application or implementing a firmware update for a piece of hardware, the associated software object will also need to be updated to reflect the changes made to the resource and any related configuration files. This can be cumbersome if a resource is continually being updated, for example when updating a given software application to fix bugs reported by users. If the software object, such as the MBean, is not up-to-date with the format of the configuration files, then inconsistencies will be introduced and the resource may be configured incorrectly. For example, if an MBean has not been updated by the developer based on a software update, the JMX management applications may throw an error when they interact with the MBean to try to retrieve configuration values that no longer exist in the configuration file.
Hence, it is an object of the present invention to provide a simple method for managing a resource. Such a method should preferably facilitate the writing and maintaining of software objects used to manage a resource within a particular software standard.